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described.  ML)  NIX  is  a  variant  of  UNIX,  an  operatinq  system 
for  the  PDP  11  developed  at  Bell  Laboratories. 

The  three  major  desiqn  qoals  of  the  system  were: 

(1)   support  for  processes  capable  of  real-time   interaction 

with   several   dynamic  qraphics  display  units,  ar>    array 

processor,  and  a  multi-channel  A/D  converter," 
( <?  )   interactive   and   hackoround   processina   facilities  to 

support  proqram  develooment;   and, 
(4)   manaqement   of   the  hierarchical  storaqe  created  by  the 

mix  of  shared  and  private  memories  of  various  speeds. 

The  resultinq  Ml) NIX  svstem  provides  an  effective  mechanism 
for  resource  sharinq  in  a  laboratory  environment  and  is  the 
basis  for  protected  real-time  operation  in  a  multi-user  sys- 
tem. 
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TNTRODUC  I  ION 

The  flavor  of  a  computer  ooeratinq  environment:  is  often 
derived  from  its  most  strinaent  processinq  reau i r emen t s . 
Thus,  real-time  systems  teno  to  Provide  very  sparse  proaram 
development  facilities*  terminal  systems  often  overlook  ade- 
quate backqround  processinq  mechanisms  or  real-time  support* 
and  batch  systems  tend  to  avoid  all  interactive  tasks.  How- 
ever* we  assert  that  any  system  seekinq  to  support  the  ac- 
tive development  of  real-time  tasks  needs  the  best  available 
software  enoineerinq  tools;  the  MUNI  X  operation  svstem  is 
the  result  of  our  efforts  to  provide  this  environment. 

tquipment  Con f i ou r a t i on 

Ihe  confirm  ration  of  the  Siqnal  Processinq  and  Display 
Laboratory  is  shown  in  Fiqure  1.  The  real-time  system  can 
be  viewed  as  a  three  bus  ensemble*  with  the  respective  func- 
tions of  data  acquisition,  siqnal  processinq*  and  display. 
When  bus  cycles  are  not  requireq  by  real-time  processes*  the 
data  acquisition  and  display  busses  support  prooram  develop- 
ment activities.  The  display  system  includes  a  <•?  5  6  K  word 
fixed  head  disk,  a  Pamtek  color  display*  a  Tektronix  4014 
display  with  enhanced  qraphics*  a  Vector  General  3D5I  sys- 
tem* a  Huqhes  Conooraohic  console*  a  data  tablet*  a  Versatek 
printer/plotter,  and  an  EPC  araphic  recorder.  Peripherals 
for  the  data  acquisition  controller  include  both  large  (96^ 
words)  and  small  (  2  .  S  M  words)  disk  systems*  magnetic  tapes* 
a    card    reader*   a   line   printer,   and   a   sixteen   line 
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programmable  terminal  multiplexer.  0  u  a  1  ported  core  memory 
(88K  words)  is  accessible  from  either  UlSilBUS.  The  siqnal 
processing  subsystem  consists  of  a  CSP  125  controller  with 
4K  words  of  125  nanosecond  memory,  an  array  processor,  and 
two  loK  word  banks  of  three  ported  memory. 

Operational  Factors 


Ihe  MJIXilX  operating  environment  is  a  university  labora- 
tory enqaqed  in  research  and  educational  use  of  computer 
graphics,  siqnal  processing,  operatina  systems,  ana  hybrid 
computinq.  Althouqh  several  operatinq  systems  (5,0,7,10] 
are  available  for  use  with  the  PDP-11  computer,  each  lacks 
capablity  in  some  dimension  which  appears  important  to  the 
present  ranqe  of  applications.  i/ve  were  thus  faced  with  the 
alternative  of  maintaining  several  operatinq  systems  for  use 
with  the  various  applications  (with  the  attendant  equipment 
schedulinq  and  program  conversion  problems)  or  developinq  a 
unified  operatinq  environment  with  subsystems  which  provide 
the  required  specialized  support  when  it  is  needed.  In  the 
oaraqraphs  which  follow,  we  present  the  key  features  of  the 
multifunction  operatina  system  (MUNIX)  which  provides  a 
support  environment  for  the  development,  maintenance,  and 
operation  of  real-time  proqrams. 

Since  program  development  is  a  major  portion  of  our 
workload,  we  sought  a  multiproqramminq  operatinq  system 
which  would  provide  us  with  interactive  terminal  support,  a 
hierarchical  file  system,  and  a  full  complement  of  prooram 
development   software   (editor,   compilers,   assembler,   and 
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utilities).  Three  other  major  considerations  were  the  ease 
of  interfacing  new  devices  to  the  operatina  system,  the 
system's  support  of  extended  addressina  (memory  management), 
and  the  availability  of  source  code.  Usino  these  criteria, 
the  UNIX  flO]  ooeratinq  system  was  chosen  as  the  basis  for 
proqram  development  support. 

Unce  the  decision  was  made  to  utilize  UNIX  as  the  basic 
operating  environment/  attention  coula  be  focused  on  the 
technical  problems  associated  with  providino  to  our  communi- 
ty of  users  an  environment  which  facilitates  the  implementa- 
tion and  dehuqginq  of  real-time  processes.  The  problem  of 
providing  user  access  to  the  full  set  of  peripherals  on  both 
processors  while  seeking  to  dynamically  balance  the  UNI  BUS 
and  processor  loads  ana  provide  real-time  support  for  the 
display  and  sional  orocessing  tasks  led  to  the  development 
of  the  symmetric  multi-processing  ooeratinq  system  discussed 
in  subsequent  sections. 

Architectural  Considerations 


A  single  bus  architecture  such  as  the  POP  11  is  not  a 
favorable  environment  for  multiprocpssino  because  each  pro- 
cessor can  only  communicate  with  the  peripherals  and  memory 
on  its  own  bus.  One  (expensive)  method  of  solvinq  this 
problem  is  to  buy  peripherals  which  are  m u It i -ported  and 
thus  capable  of  communicatinq  with  more  than  one  bus?  anoth- 
er approach  uses  special  purpose  bus  switches  which  toagle 
one  peripheral  between  the  two  busses.  In  liqht  of  the 
presently   available   switch   technoloqy»   this  solution  was 

-5- 


also  rejected  as  economically  infpasihle. 

Except  for  the  disk  storage  unit  and  core  memory,  MUNIX 
swaps  processes  between  the  two  processors  in  order  to  meet 
peripheral  access  requirements.  Thus,  the  access  problem 
was  solved  without  the  benefit  of  special  purpose  bus 
switches  or  multi -ported  peripherals.  Hus  traffic  is  spread 
across  both  busses  and  only  those  processes  which  must  ac- 
cess devices  on  both  busses  will  incur  the  shared  access 
overhead.  We  helieve  this  solution  to  be  appropriate  for  use 
in  real-time  systems  in  which  the  real-time  device  access 
can  he  confined  to  a  specific  bus. 

Another  problem  which  required  attention  was  the  con- 
trolled utilization  of  the  several  kinds  of  memory  available 
in  the  system.  In  a  system  with  a  small  (18-bit)  address 
r  a  n  q  e  ,  each  paae  frame  is  extremely  valuable?  thus,  it  is 
desirable  for  special  purpose  memory  to  be  available  for 
qeneral  allocation  whenever  it  is  not  renuired  for  real-time 
ope  rat  ion. 
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MULTIPROCFSSING 

M  U  N  I  X  is  a  t  iqht 1 y-counl ed  symmetric  multiprocessor 
ooprat  inq  system  which  is  d  e  s  i  o  n  e  d  to  provide  a  mechanism 
for  bus  ano  processor  load  balancing  as  well  as  a  uniform 
user  interface  to  a  wide  vanity  of  system  peripherals.  In 
aeneral »  the  desiqn  is  similar  to  other  multiprocessor  sys- 
tems 11/2/4/9]  -  -  the  single  copy  of  the  system  residing  in 
shared  memory  uses  P  and  V  operators  [H]  for  synchroniza- 
tion. The  processors  are  completely  independent/  each  ooing 
its  own  user  process  selection  from  a  sinqle  ready  process 
list.  In  order  to  facilitate  processor  i den t i  f i c a t i on  ,  the 
hardware  was  modified  so  that  the  three  unused  bits  in  the 
processor  status  word  (bits  8-10)  contain  a  unique  processor 
i  dent  i  f  i  er . 

As  Fioure  1  indicates*  the  hardware  is  not  symmetrical 
with  respect  to  1/0  devices  on  the  two  UNIHUS's.  The  most 
important  devices/  bulk  memory  and  the  larae  disk  storage 
unit,  are  dual-ported  and  can  be  accessed  by  processes  run- 
ninq  on  either  processor;  all  other  devices  are  single- 
ported  and  may  only  be  accessed  by  their  host  processor. 
Most  multiprocessor  operating  systems  avoid  this  problem  by 
employing  1/U  controllers  or  channels  which  communicate  with 
all  processors.  Since  the  concept  of  a  UN  IB US  communicating 
with  more  than  one  processor  is  foreign  to  the  PDP-11 
hardware  design/  another  solution  to  the  I/O  control  problem 
had  to  be  found  for  MllMX. 
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Processor  Affinity 

Hpcausp  the  distribution  of  devices  across  the  two 
busses  in  the  system  is  not  symmetric/  the  concept  of  pro- 
cessor affinity  was  introduced  into  MUNIX.  Processor  affin- 
ity may  be  reouested  by  the  user  or  the  system,  and  may  be 
permanent  or  temporary,  and  may  have  be  advisory  or  mandato- 
ry status.  The  use  of  each  of  these  types  of  processor 
affinity  is  discussed  in  the  following  paragraphs. 

It  is  not  feasible  to  make  a  Priori  determination  of  the 
I/O  device  reouirements  of  all  processes  nor  is  it  desirable 
to  limit  a  process  to  the  peripherals  attached  to  only  one 
bus?  therefore,  MUM  IX  supports  dynamic  process-processor 
affinity.  It  appears  desirable  to  determine  device  availa- 
bility in  a  truly  dynamic  fashion,  with  each  processor  ini- 
tiating all  user  I/O  requests  as  though  all  devices  were 
available  on  both  buses.  Only  when  this  access  attempt  had 
failed  (as  indicated  by  an  addressing  error)  would  the  pro- 
cess be  passed  to  the  other  processor  where  the  I/O  would 
aqain  be  initiated.  Unfortunately,  much  of  the  system  I/O 
set-up  has  to  he  repeated  by  the  second  processor,  and  in 
addition,  the  time  for  the  hardware  to  discover  and  report 
device  nonexistence  varies  between  five  and  ten  microseconds 
and  stops  all  bus  activity.  This  scheme  would  have  made 
device  reconfiguration  simple  but  was  abandoned  because  of 
excessive  system  overhead. 

In  the  current  implementation,  MUNIX  maintains  a  dynamic 
configuration  table  which  lists  the  devices  on   each   UN  IB US 
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(the  multi-ported  Devices  are  in  both  lists).  When  a  oro- 
cess  requests  an  I/O  operation,  M  U  M  X  determines  if  the 
required  device  can  be  accessed  by  the  processor  which  is 
currently  servicina  the  process.  If  not,  a  temporary  pro- 
cessor affinity  flaq  is  set  and  the  user  task  is  suspended. 
When  next  schedulinq  this  task  for  a  orocessor,  the  system 
uses  the  temporary  affinity  flaa  to  insure  that  the  correct 
processor  is  chosen.  When  the  I/O  operation  is  completeo, 
the  temporary  affinity  flaa  is  cleared  and  the  process  is 
once  aqain  a  candidate  for  execution  by  either  processor. 

In  oroer  to  decrease  schedulinq  overhead,  a  permanent 
processor  affinity  flaq  is  provided  for  processes  which  do 
larqe  amounts  of  1/0  to  devicps  which  are  accessible  from 
only  one  hus.  lhis  flaq  is  set  by  the  user  process  via  a 
system  call  which  specifies  the  device  required  by  thp  user; 
MOM  X  uses  the  configuration  table  to  translate  this  request 
into  the  appropriate  permanent  affinity  flaa.  Once  set, 
this  advisory  flaq  is  used  by  the  processor  scheduler.  As 
lonq  as  more  than  one  process  is  ready  for  execution,  a  pro- 
cess with  the  permanent  affinity  flaa  will  only  be  scheduled 
on  the  desired  processor.  If  only  one  process  is  ready, 
however,  it  will  be  executed  by  either  processor  since  the 
alternative  is  an  idle  processor.  A  process  with  the  per- 
manent affinity  flaq  set  will  be  temporarily  switched  in 
order  to  access  an  I/O  device  on  the  other  UMBOS.  Neutral 
processor  affinity  is  the  default  for  non-real-time 
processes . 
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Active  Process  Stack 

MO NIX  solves  the  problem  of  account  ma  for  a  separate 
stack  for  each  processor  in  a  r  a  t  h  p  r  clean,  straight-forward 
manner.  With  each  user  process  the  system  associates  \0?H 
bytes  of  storaoe.  This  reqion  contains  system  per-process 
data  and  the  system  stack  for  this  nrocess.  When  attention 
is  switched  from  one  process  to  another,  it  is  sufficient  to 
simply  change  the  system  stack  seqment  reqister  to  point  to 
the  header  ar^a  of  the  new  process  and  reload  the  stack 
pointer?  the  state  of  that  process  is  thereby  completely 
restored.  This  scheme  is  sufficiently  general  to  allow  cap- 
ture of  a  nested  interrupt  state  as  well  as  the  normal  user 
state.  Since  this  elegant  scheme  was  used  in  the  UNIX 
monoprocess i ng  system  (101,  no  change  was  required  to  allow 
mul t  iprocessinq. 
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MEMOWY  HIEWAKCHY  MANAGEMENT 

As  indicated  in  Fiqure  e>  *  the  system  primary  memory  is 
rather  unusual.  Each  processor's  memory  space  consists  of 
1  fo  K  words  of  '-ISO  nanosecond  M 0 S  memory  which  is  private/  1  6  K 
words  of  fi 5 0  nanosecond  cor?  memory  which  is  shared  with  the 
CSP  ar r ay  processor*  and  HHK  woras  of  8  0  0  nanosecond  core 
which  is  shared  between  the  POP  11/50  processors.  The 
operating  system  occupies  2  4  K  words  of  the  shared  memory. 

M U N 1 X  provides  each  user  nroqram  with  a  virtual  memory 
of  up  to  3  2  K  words  which  is  divided  by  the  memory  management 
hardware  into  eight  paqes  of  4K  words  each.  Having  thirtv- 
two  page  frames  at  its  disposal*  the  memory  management 
software  utilizes  a  workinn  set  algorithm  (31  for  page  re- 
p 1 acemen t . 

When  there  are  no  real-time  processes  active*  the  memory 
manager  uses  both  private  and  shared  page  frames  uniformly 
except  for  the  restriction  that  pages  from  one  process  can 
not  reside  simultaneously  in  both  private  memories.  Obvi- 
ously* a  process  which  has  one  or  more  pages  in  a  private 
memory  can  only  be  executed  by  one  processor.  Tf  this  pro- 
cess must  use  the  other  processor  to  access  a  peripheral 
device*  any  pages  in  private  memory  are  moved  to  the  shared 
memory  before  the  temporary  affinity  flag  is  set.  Since 
this  move  involves  significant  overhead  (the  PDP  11  has  no 
block  move  instruction)*  the  system  attempts  to  avoid  this 
situation  by  assigning  the  private  memory  to  processes  which 
have  the  permanent  affinity  f 1  an  set  wherever  possible. 
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when  a  process  is  a  ran  ted  real-time  status*  the  memory 
manaqemen t  software  removes  the  paces  of  all  other  procfsscs 
from  the  private  memory  of  the  desired  processor.  If  paqe 
frames  are  available  and  the  process  status  warrants*  these 
paqes  are  moved  to  shared  memory;  otherwise*  they  are.  moved 
to  the  swap  file.  Once  the  private  memory  is  cleared*  all 
of  the  paqes  of  the  new  real-time  process  are  moved  from 
wherever  they  reside  (the  other  private  memory*  shared 
memory*  or  the  swap  file)  and  locked  so  that  they  will  never 
be  swapped.  This  move  may  involve  a  transfer  to  and  from 
the  swap  file  if  the  paqe  happened  to  reside  in  the  wronq 
private  memory.  Once  moved*  the  real-time  process  is  exe- 
cuted from  the  fastest  memory  on  the  system. 


-13- 


PPOCtSS  CONTROL 

M  0  f\i  I  X  supports  three  types  of  processes:  foreground 
(timeshared),  background  (hatch),  and  real-time.  Since  the 
control  and  capability  of  the  first  two  types  of  processes 
have  been  reported  pise where  110],  this  paper  will  concen- 
trate on  real-time  process  support. 

One  of  the  primary  functions  of  the  Signal  Processing 
and  Display  Laboratory  is  to  support  signal  acguisition  and 
analysis.  To  accomplish  this  task,  an  analogue  signal  is 
digitized  and  then  sent  to  the  data  acquisition  process. 
This  process  loas  the  data  and  does  some  front  end  analysis 
before  passino  it  to  the  CSP  1?S  with  its  array  processor 
where  the  signal  is  processed  usinq  Fourier  transform  tech- 
niques. The  transformed  data  is  then  passed  to  a  real-time 
display  process  which  presents  the  data  on  one  or  more  of 
the  graphic  display  devices  in  the  system.  Both  the  data 
acguisition  process  and  the  display  process  operate  under 
severe  time  constraints.  In  order  to  support  this  type  of 
computinq,  M  U  N I X  provides  a  r  e  a  1  - 1  i  m  p  process  classifica- 
tion. 

Peal-Time  Processes 

All  processes  beoin  as  either  forearound  or  background. 
After  a  process  starts  execution,  it  can  request,  via  a  sys- 
tem call,  that  it  becomp  a  real-time  process.  Since  a 
real-time  process  is  by  definition  attempting  to  respond  to 
some  external  stimulus  (device),   these   processes   must   be 
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executed  on  the  processor  whose  U NIB  US  is  connected  to  the 
desired  device.  Therefore,  every  real-time  process  has  a 
permanent  processor  affinity  which  is  mandatory  rather  than 
adv  isory. 

When  a  process  requests  real-time  status?  the  system 
makes  two  limit  checks.  First,  it  determines  the  number  of 
real-time  processes  in  existence  with  ^n  affinity  for  the 
desired  processor.  Tf  this  number  is  equal  to  a  maximum 
value  (currently  one),  the  rpauest  is  denied.  Second,  it 
checks  the  total  amount  of  memory  dedicated  to  real-time 
processes.  If  this  amount  plus  the  amount  required  for  the 
request  inq  process  is  oreater  than  a  maximum  value  (current- 
ly b4K  words),  the  request  is  denied.  These  limit  checks 
enforce  the  system  policy  of  not  allocatinq  system  resources 
to  real-time  processes  to  the  point  of  severly  deqradinq 
system  response  to  other  users.  Both  of  these  restrictions 
are  merely  administrative,  system  is  concerned  althouqh  the 
policy  of  allocatinq  only  private  memory  to  real-time 
processes  obviously  must  be  discarded  if  such  processes  are 
allowed  to  occupy  more  than  6  4  K  .  The  problem  of  multiple 
real-time  processes  comoetinq  for  the  same  processor  is 
solved  by  a  dynamic  system  limit  on  the  number  of  consecu- 
tive quanta  which  will  be  allotted  to  a  real-time  process 
when  other  processes  with  sufficiently  hiqh  priority  are 
waitinq. 

If  the  real-time  request  can  be  qranted,  the  request inq 
process  is  moved  into  the  private  memory  of  the  specfied 
processor  (Fiqure  ?),  possibly  dislocatino  some  non rea 1 -t i me 
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processes.  After  this  move*  the  process  is  locked  into 
memory  so  that  it  is  never  a  candidate  for  swappina  and  is 
given  the  hiahest  possible  priority.  Ihus»  whenever  a 
real-time  process  becomes  ready  for  execution,  it  is  preemp- 
tively allocated  a  processor  and  keeps  possession  of  this 
processor  until  it  completes  or  until  an  T/0  request  causes 
it  to  be  blocked. 

Array  Processing  and  Real-Time  I/O 

As  indicated  in  Figure  ? ,  the  upper  16 K  words  of  each 
processor's  private  memory  is  shared  with  the  CSP-1^5.  In 
order  to  reduce  the  overhead  involved  in  communication 
between  a  real-time  process  and  the  CSP,  this  memory  is  made 
a  portion  of  the  real-time  process  address  space.  Thus,  a 
process  which  wishes  to  communicate  with  the  array  processor 
need  only  store  the  data  in  the  upper  lbK  words  of  its  own 
address  space  and  request  the  operating  system  to  send  an 
interrupt.  Similarly,  data  cominq  from  the  array  processor 
is  placed  directly  into  the  address  space  of  a  real-time 
process  and  thereby  saves  the  system  overhead  involved  in  a 
block  move?  an  input  data  ready  interrupt  is  also  provided. 

Interactive  Graphics 


In  addition  to  accomplishing  very  efficient  communica- 
tion with  the  array  processor,  the  method  chosen  for  sup- 
porting real-time  processes  solves  a  problem  which  would 
have  been  difficult  to  solve  in  any  other  manner.  One  of 
the  graphic  display  units  in  the  system,   a   Vector   General 
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3D3T,  is  a  refresh  device  which  retrieves  and  interprets  a 
display  list  forty  times  a  second.  The  display  list  con- 
tains not  only  physical  memory  addresses  to  be  used  in 
direct  memory  access  transfers,  hut  also  instructions  which 
can  cause  the  display  to  store  information  anywhere  within 
the  4<fh  word  seament  of  memory  which  contains  the  display 
list.  Althouqh  NUJNIX  can  control  seqment  access,  there  is 
no  effective  mechanism  for  control  1  inq  intra-seqment  memory 
references  in  a  user's  display  list  since  the  hardware  ap- 
plies neither  memory  protection  nor  relocation  to  these 
memory  accesses. 

Since  the  display  list  is  ouite  larqe  and  complex,  it  is 
not  feasible  to  have  the  operatinq  system  build  a  valid  list 
from  parameters  supplied  hy  the  user,  or  verify  a  user's 
list  before  it  is  sent  to  the  display  controller.  However, 
if  the  user  were  allowed  to  send  an  arbitrary  (unchecked) 
display  list  to  the  display  controller,  M  U  N  I  X  coulo  not 
insure  the  inteqrity  of  any  other  process  residing  in  the 
same  3  <?  K  memory  seament.  Our  solution  to  this  problem  is  to 
require  a  real-time  classification  for  all  processes  which 
use  this  display  unit.  As  noted  earlier,  real-time 
processes  are  placed  in  the  3  <?  K  word  private  memory  seqment 
and  all  other  processes  are  removed  from  this  area. 
Thereafter,  the  user  process  is  allowed  to  specify  the 
display  list  which  the  operatina  svstem  sends  to  the  aisplay 
controller  unchecked.  The  worst  consequence  of  an  invalid 
display  list  in  this  environment  is  that  it  may  destroy  the 
process  which  built  the  list. 
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System  Parti tioninq 

Another  interesting  by-product  of  the  real-time  process 
control  is  a  very  simple  method  for  dynamic  system  parti- 
tioning. Since  the  private  memory  of  each  processor  is  the 
low  order  3  e>  K  words  of  address  space,  it  is  very  easy  to 
separate  one  processor,  its  private  memory,  and  its  I/O  dev- 
ices. Unce  separated,  this  oortion  of  the  hardware  can  be 
used  to  run  other  operating  systems  or  to  test  stand-alone 
programs.  In  tact,  thp  stand-alone  orogram  or  operating 
system  can  be  built  in  the  M U M IX  environment,  loaded  into 
the  private  memory  as  a  real-time  process  and  then  be  given 
complete  control  of  the  hardware  environment  as  MUNIX  re- 
verts to  a  monoprocessino  system  to  continue  serving  its 
other  users. 
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CONCLUSlUNS  AND  FUTURES 

Uur  major  efforts  to  date  have  been  toward  implementa- 
tion of  a  loaical  ly  correct  M  U  N I X  system  which  makes  only 
thoses  chanaes  to  UNIX  reauirfd  hy  the  structural  differ- 
ences of  the  present  operat inn  environment.  The  limited 
experience  we  have  had  to  date  on  Ni  1 1  l\l  I X  has  served  to  con- 
firm our  basic  desion  decisions.  Support ina  all  facets  of 
real-time  proqramminq  within  a  uniform  environment  has 
greatly  simplified  the  overall  system  desian. 

With  each  task  taking  its  respective  place  in  a  service 
hierarchy*  the  available  system  caoacity  can  be  dynamically 
allocated  to  the  priority  process*  thereby  avoiding  worst 
case  a  priori  resource  allocation.  This  approach  has  had 
the  further  advantaoe  of  providino  a  vehicle  for  rapid  (less 
than  six  months  elapsed  time)  development  of  a  sophisticated 
system  by  a  small  proqramminq  aroup  {£  faculty*  b  graduate 
students). 

Other  completed  work  includes  the  development  of  a 
dynamic  symbolic  debuogino  tool*  development  of  numerous 
on-line  diagnostic  packaoes  and  I/O  device  drivers*  develop- 
ment of  a  line  editor  which  facilitates  correction  of  typing 
mistakes  on  the  interactive  level*  and  enhancements  to  the 
text  editor*  the  text  processor*  and  the  linking  loader, 
ftork  presently  underway  includes  a  performance  measurement 
subsystem*  several  adaptive  schedulers*  a  virtual  machine 
monitor*  and  a  hardened  file  system. 
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